\section*{Features and Cuts}

\subsection*{Features}

Regarding the features that we laid out in the SRS, we have completed
many of the major features we listed.  These features include:

\begin{itemize*}
\item a tracking system website - a way to visually track the progress
  of packages sent by clients
\item an ETA system - a way for lab technicians to see incoming
  package volume
\item configurable views - each level of user will have a specialized
  view in the tracking system
\item data logging - information of previous and current packages are
  stored for reference
\item dynamic updates - updates of information are propagated to their
  respective groups
\item an Android application - to make the courier's job more
  methodical and less error-prone which include:
  \begin{itemize*}
  \item dynamic routes/packages - routes and package updates will be
    seen in the application
  \item Google maps - used for directions and routing of couriers
  \item checklists - beginning and ending shift checklists as well as
    client checklists/instructions
  \item barcode scanning - scanning of package barcodes that update
    package status
  \end{itemize*}
\end{itemize*}

Despite completing many, if not all, of our major features listed, we
were not able to complete any of the extra features and frills we
listed. We had intended to create a tutorial version of our Android
application so that couriers could learn the ropes without affecting
the real tracking system. We also intended to create an aggregated
display of package data so that lab technicians could compare data if
needed. We would have liked to implement these features as we believe
that they will be helpful, but not necessary. The reason why these
were not implemented was essentially due to time constraints. We did
not realize how long it would actually take to implement our major
features, but after we realized it, we decided not to implement these
extras.

During the development process, our customer provided us with additional
features or pieces that they wished to have added. Some of them we were
unable to accommodate in the time available, while others we easily
added. For example, within the configurable views, the customer wanted
to have separate read/write privileges for each user level, which we
were unable to add due to time. Another requested part of a feature was
the ability to add multiple items on the tracking system website, which 
with our set up was an easy addition to make so we did. Another that
we added was showing the username of the user logged in currently, 
and many others.

\subsection*{Cuts}

Besides the extra features that we had mentioned above, there weren't
many cuts at all.  The cuts that we did were more like parts of a
feature that necessarily did not need to be implemented at the
time. One example of a part of a feature we cut was the read/writing
privileges of a certain user account. The feature was asked for late
into our development, while we still had the major features to be
implemented. The time we saved most likely would be a few hours of
refactoring code to use the new user level internally. Another example
of a part of a feature cut is the ability to change/remove packages
from the database. We choose to cut this because we had an option to
add packages already and other features needed to be completed
first. Despite all of this, we actually either already have the
internal capability of the requested feature, or the backend can
easily be scaled to include the requested feature. For example, we
actually have change/remove capabilities, it just isn't exposed to the
user yet. We can easily set read/write privileges by adding another
field to an already existing object. Even though we may have had to
made cuts, we made sure that it was possible to do it when we have the
time.
